home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / August 96 / FW_CContent and Selections < prev    next >
Encoding:
Internet Message Format  |  1996-08-15  |  2.2 KB  |  [TEXT/ttxt]
  1. Subject:     FW_CContent and Selections
  2. Sent:        7/10/96 2:21 PM
  3. Received:    7/10/96 2:41 PM
  4. From:        Victor Langelo, victor@eclipse.cpcn.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8.  
  9.  FW_CContent and Selections
  10.  7/10/96            2:43 PM
  11. I would argue against too many frameworked defined Notification
  12. classes, unless they are used explicitly by the framework. The users
  13. content model will seldom be a simple as the example parts.
  14.  
  15. FW_CContent has a compiler generated default copy constructor.
  16. Hopefully, the ODF team will and an explicit one when it becomes
  17. necessary. Any subclasses can define one as needed. Since there
  18. is only one data member in FW_CContent, it hardly makes sense
  19. and hurts compiler optimization to add one.
  20.  
  21. Besides, if your part has a lot of data, making a copy of the entire
  22. content is not a useful way to save the undo state.
  23.  
  24. This leads me to another problem. It is difficult for us to support
  25. undo with the current interface to FW_CSelection::ClearSelection.
  26. We really need another parameter, preferrably a FW_CContent*.
  27. I realize that could be NULL in the default case, but we have an
  28. error prone work-around of setting the undo context for each 
  29. possible ClearSelection from the framework base commands. If
  30. the commands keep an undo content pointer, which would be set by
  31. subclasses and then passed it in each ClearSelection message, it
  32. would be a big improvement.
  33.  
  34. --------------------------------------
  35. From: Hewitt-Jon
  36.  
  37. o More notification classes would be useful, i.e. FW_CBecameTargetNotification,
  38. FW_CResignedTargetNotification, FW_CEditViewChangedNotification, etc.
  39.  
  40. o It seems like it would be useful to be able to copy and assign content
  41. objects.  For example, if you want to be able to undo a drop of a part of the
  42. same type, a command class could just retain a copy of the content as the saved
  43. data.  FW_Content lacks an explicit copy constructor and assignment operator.
  44. The compiler generated versions look safe to use for the current class but that
  45. is no guarantee that they will remain safe. Does it make sense to add an
  46. explicit copy constructor and assignment operator?  Or should I use a
  47. stream/archiving to duplicate the content's data?
  48.  
  49.  
  50.  
  51.  
  52.